Although computers generally make information more readily available, in some situations the way information is stored on a computer system may hinder access to the information. In particular, differences in how information is structured may cause problems when one tries to start using tools developed in one historic context to access or manipulate information which arose in a different context.
Relational databases are among the oldest and best understood structures in computer science. They were in use on mainframes long before client-server networks or the Internet became part of the information technology world. Relational databases are used by businesses to store and manipulate information on everything from inventory to payroll, by government agencies to track everything from taxes to building licenses, and by individuals for an equally wide variety of purposes. Dozens of popular relational database programs are commercially available.
Not surprisingly, many of the relational database programs available are not consistent with one another. Some attempts have been made to define standards, but they have not been entirely successful. Many, but not all, relational database tools accept at least a subset of some version of the database query language known as Structured Query Language ("SQL"). Many, but not all, relational database tools also conform to at least a subset of some version of the interface standard known as the Open Database Connectivity standard ("ODBC"). Access according to the ODBC standard is possible using various drivers, such as the PureJava JDBC driver (PUREJAVA and JDBC are trademarks of Sun Microsystems, Inc.).
The ODBC standard defines an interface which can be used by applications or other database tools to access a variety of databases. The interface makes each database appear (more or less) the same to a given database tool. This is accomplished by using different "driver" software for each different database. A "driver manager" is typically also provided. The driver manager helps pass information between a given database tool and the driver(s) for the database(s) being accessed by the tool.
Unlike relational databases, "directory service" structures are a relatively recent development in information technology. The need for directory services became clear only after computer networks became a prominent part of the information landscape and grew so large and complex that their administration required full-time attention from specialists. Directory services are sometimes referred to as "naming services."
A variety of directory service providers are now available to help administer both the location of network resources and the rights of network users to use those resources. Many, but not all, directory service tools conform at least in part with the X.500 directory services standard. One well-known directory service system includes NetWare Directory Services software commercially available from Novell, Inc. of Provo, Utah (NETWARE DIRECTORY SERVICES is a trademark of Novell, Inc.). As used herein, "Novell Directory Services" ("NDS") includes NetWare Directory Services and any other directory service commercially available from Novell, Inc.
In contexts other than the present one, a directory services repository is sometimes called a directory services "database." Both repositories and databases may be distributed, because that is mainly a matter of storage and locks for enforcing consistency, rather than a question of the basic internal structure. But "database" and "repository" are not interchangeable in the present context.
A repository supports naming services. Each repository is organized hierarchically, as one or more trees. Each object in a tree (except the root object) has exactly one parent. Objects may generally have children, which may inherit properties from their ancestor objects. Objects are instances of "classes," as described in detail below.
By contrast, "database" as used herein refers to a relational database. A given database may support any of a wide variety of commercial or personal activities. Each database is organized as a set of tables in which rows represent records and columns represent record fields. Certain fields may be found in multiple tables, and the values of these "key" or "index" fields are used to guide database searches. Database access and manipulation involve combining information from various tables into new combinations to obtain different views of the data.
In short, databases and repositories arose at different times to meet different needs, and have different structures and capabilities. There is no need to dwell further here on the details of relational database structure, SQL, or ODBC, as numerous references on those topics are widely available. Many computer science professionals have also taken at least one course in databases.
However, the details of directory service repositories are less familiar to many people, so they are summarized here. At least one NDS directory services provider includes a schema. The schema includes a set of "attribute syntax" definitions, a set of "attribute" definitions, and a set of "repository object class" definitions. The NDS software and a default NDS schema are described in Bierer et al., NetWare 4 for Professionals, ISBN 1-56205-217-9 ("NetWare 4"), pages 255-342. The terms "attribute" and "property" are used interchangeably in NetWare 4 and herein, as are the terms "attribute syntax" and "property syntax."
Each attribute syntax in the schema is specified by an attribute syntax name and the kind and/or range of values that can be assigned to attributes of the given attribute syntax type. Attribute syntaxes include, without limitation, Case Exact String (case-sensitive string), Case Ignore List (case-insensitive string list), E-Mail Address, Net Address (valid addresses include IPX and AppleTalk), Path, and Stream. Attribute syntaxes correspond roughly to data types such as integer, float, string, file, stream, or Boolean, or to collections of these types, in conventional programming languages.
Each attribute in the schema has certain information associated with it. Each attribute has an attribute name and an attribute syntax type. The attribute name identifies the attribute, while the attribute syntax limits the values that are assumed by the attribute. For instance, the default NDS schema includes an attribute of syntax type integer having the name "supported connections" which specifies the number of concurrent connections a file server allows.
Each attribute may also have associated with it any or all of the following flags: Non-removable, Hidden, Public Read, Read Only, Single-Valued, Sized, and String. The general meanings of these flags are familiar to those of skill in the art. If the Sized flag is set for a given attribute, then upper and lower bounds (possibly including No Limit) are imposed on values to be held by that attribute.
Each repository object class in the schema also has certain information associated with it. Each repository object class has a class name which identifies it, a set of super classes that identifies the other classes from which this class inherits attributes, and a set of containment classes that identifies the classes permitted to contain instances of this class.
Each repository object class also has a container flag and an effective flag. The container flag indicates whether the class is a container class, that is, whether it is capable of containing instances of other repository object classes. The effective flag indicates whether instances of the class (objects) can be defined. Non-effective repository object classes are used only to define attributes that will be inherited by other classes, whereas effective classes are used to define inheritable attributes, to define instances, or to define both.
In addition, each repository object class groups together certain attributes. The naming attributes of a repository object class are those attributes that can be used to name objects belonging to the class. The mandatory attributes of a repository object class are those attributes that must exist in each valid instance of the class and/or become mandatory attributes of classes which inherit from the class. The optional attributes of a repository object class are those attributes that may, but need not, exist in each valid instance of the class. Optional attributes of a parent class become optional attributes of a child class which inherits from the parent class, unless the attributes are mandatory in some other parent class from which the child inherits, in which case they are also mandatory in the child.
A repository object is an instance of a repository object class. Different repository objects of the same class have the same mandatory attributes but may have different current values in their corresponding mandatory attributes. Different repository objects of the same class may have different optional attributes, and/or different current values in their corresponding optional attributes.
A repository object may be identified in various ways. According to the most visible method, users concatenate legible mnemonic names to create a distinguished name of the type familiar to users of Novell NetWare software. A "common name" forms the terminal part of a distinguished name, with the rest of the distinguished name providing a context for the common name so that different objects can have the same common name.
Networking and directory service software may also use identifiers not typically seen by users. For instance, directory services software translates between distinguished names and common names, on the one hand, and non-mnemonic internal identifiers such as GUIDs, tuned names, tree names, and replica identifiers, on the other hand.
The directory services provider also includes a directory services interface library which provides access to a repository and possibly to the schema as well. The schema may be an API-extensible schema in that the attributes and object classes found in the schema can be altered through a schema Application Program Interface ("API") without direct access to the source code that implements the schema. In some embodiments the directory services interface library includes tables or commands stored in a file which is read by the schema during its initialization and when repository objects are created, thereby defining the available attributes and classes.
The directory services interface library includes a set of routines that are available to other code to access and modify the repository and possibly also the schema. One implementation of the directory services interface library includes an NWDSxxx() library that is commercially available as an API from Novell, Inc. of Orem, Utah. The NWDSxxx() library is so named because the names of functions and data types defined in the library typically begin with "NWDS," an acronym for "NetWare Directory Services." It would be a straightforward task for one of skill in the art to access the NWDSxxx() API from code written in C or C++ or a similar programming language. Another implementation of the directory services interface library includes the Java Naming and Directory Interface ("JNDI") API. (JNDI is a trademark of Sun Microsystems, Inc.).
The directory services repository contains repository objects that are defined according to the schema and the particulars of the network. These objects typically represent resources of the network. The repository is a "hierarchical" repository because the objects in the repository are connected in a hierarchical tree structure. Objects in the tree that can contain other objects are called "container objects" and must be instances of a container object class.
The repository may also be a "synchronized-partition" repository. Such a repository is typically divided into two or more non-overlapping partitions. To improve the response time to repository queries and to provide fault-tolerance, a replica of each partition is physically stored on one or more file servers in the network. The replicas of a given partition are regularly updated by the directory services provider through an automated synchronization process, thereby reducing the differences between replicas caused by activity on the network.
Although directory services are extremely useful, access to the information in a repository is currently limited. The NDS API and other known directory service interfaces do not accept SQL and do not conform with ODBC. Thus, tools such as report generators configured for databases cannot be readily used to access or process the information in a repository.
Yet another source of information available on some servers is the NetWare Core Protocol API ("NCP API"), which provides access to capabilities such as load and efficiency statistics, connection making or breaking, file and directory handling, printing, security enforcement, and drive mapping changes. The NCP API does not accept SQL and does not conform with ODBC.
Thus, it would be an advancement in the art to provide a novel system and method for making the information in a directory service repository accessible to tools that were designed and written to access or manipulate relational databases.
It would be an additional advancement to provide such a system and method which make repository information accessible to tools that use SQL and/or conform with ODBC.
It would also be an advancement to provide such a system and method which makes the information stored by NCP software available in a relational database format.
Such a method and system are disclosed and claimed herein.